Truthfully, though we didn't change the behavior with the upgrade, we should really look at this controller in more depth. The logic is convoluted and it's demonstrating a really bad pattern of HTTP responses where any downstream failures are returned to the caller as an HTTP 400 (Bad Request) indicating "you did something wrong when sending your payload and you need to fix it for this to work."

The coding conventions also often cut against best practices for C#. For example:

try
{
    ...
}
catch (Exception ex) when (ex is SomeExceptionType)
{
    ...
}

Should just be:

try
{
    ...
}
catch (SomeExceptionType ex)
{
    ...
}

We have known the existence of this problem, we will improve the logic after completing all migrations. Our primary task is upgrading sdk from t1 to t2.

I realize this request expands the scope, but let's get a better design here as well. Do you want to take a stab at it with Jesse's recommendation above or do you need further guidance?

We will take a stab at it, but it maybe takes a few time.

Did you resolve this?

@jongio,@jsquire We tried to make some changes in exception handing. Do you think this is ok or we need to subdivide BadRequest exception further?